问渠那得清如许，唯有源头活水来——以案例解析开源软件的法律及商业风险
问渠那得清如许，为有源头活水来。我们已经享受了四十年开源软件的红利，基础开始、从底层开始创建、经营开源项目对我们的创新能力提出了挑战，这同时也是一个机遇，让我们能够有机会建立自己的规则，树立自己的话语权，从而把基础和核心掌握在自己手里。
开源软件发展到现在已经有四十多年的历史，如今已经渗透到各行各业，涵盖了科技、生活的方方面面。根据Github年度报告，全球90%的公司在使用开源软件，全球财富前100企业中超过90%在使用Github开源项目。在新兴领域，开源更是紧跟技术趋势，在开发框架领域的开源项目占比25%，人工智能领域的开源项目占比15%，文档类开源项目占比15%，云原生和编程语言领域的开源项目占比也达到10%，全球开源项目已基本覆盖当前主流的技术领域[i]。对中国而言，参与开源的方式主要还是使用和贡献，根据CSDN发布的《2022中国开源贡献度报告》，中国开源贡献者数量占全球的9.5%，全球公司开源贡献榜前50中的五分之一是中国贡献的。
对于大多数使用者来说，开源软件的“自由共享、开放协作”精神已经深入骨髓，但是很多人并未意识到开源软件的自由和开放并不意味着免费和随意使用。虽然在开源软件的前身——自由软件确实秉持的是所有软件都应对所有人公开的共享哲学，但随着自由软件逐渐发展成为开源软件，再进一步发展到包括开源商业运作、开源社区运营和开源风险治理一系列链条的开源生态，开源软件的内涵和外延均发生了很大的变化。开源生态是以开源项目为中心构建，包括贡献者组成的开源社区、各行业开源者以及各行业使用者这五类产业链要素。开源商业模式是一种创新模式，其采用开放源代码、自由分发等形式减少了营销和销售的成本；通过放弃部分信息不对称产生的潜在利润，换取一定的传播和场景触及率，以已达到引领生态流量和技术路径的目标i。可以说，开源商业化根植于开源生态，开源生态为开源商业化提供了土壤和环境。
对开源生态的运用和对开源的商业化都离不开开源许可协议（以下或称“许可证”），开源协议是对开源软件所涉及的著作权、专利权、商标权等多种知识产权权属的总括性规范，是开源生态的法律基础，也是开源产业可持续发展的制度性保障。开源软件实际上受不同类别的知识产权的全方位保护——开源软件的代码本身作为计算机程序作品，享有著作权，开源软件可以申请涉及计算机程序架构的发明，可享有专利权，开源软件名称可以注册商标，享有商标专用权，有一定影响的软件名称还可受反不正当竞争法保护。基于开源协议的合同属性，其通过约定的形式将自己的部分或全部知识产权的相关权利让渡给了使用者，从而使任何人都拥有对该作品及其衍生品的使用、修改和重新发布的自由，前提是使用者必须遵守相应的许可协议。如果使用者违反了开源许可协议，那么对该作品的使用、修改和发布就有侵权源代码著作权的风险，同时也可能引发商标侵权风险。除了法律风险，开源项目的商业运用除受到开源协议的制约，还可能因开源软件本身的开放属性而产生一定风险。
以下通过案例探讨开源软件使用中的法律风险和其他风险。
Part 01
一、法律风险
1、因不遵守开源协议导致的侵权风险
国内外的司法案例基本均确认了开源协议的合同性质，这为授权人在享有著作权的情况下通过许可协议的形式将其权利进行有条件的许可或让渡提供了法理依据。对于开源软件的使用者而言，不遵守开源协议而导致侵犯开源软件的著作权，是开源软件使用中最为突出的风险。
在“罗盒”案中，法院确定了开源协议的合同属性，认为该协议授予用户复制、修改、再发布等权利，首先授权人采用开源许可证发布源代码，将自己的大部分著作权授予不特定用户，完全是出于自愿，这属于类似合同邀约的意思表示；用户通过在该许可证下复制、修改或再发布源代码的行为，对许可证作出承诺，也是出于自愿，类似于同意邀约的意思表示。在双方用行为做出完全自愿的表示之下，这个合同就成立了，同时许可证发生法律效力。基于许可证对双方有约束力的情况下，再看该许可证是如何具体约定双方的权利义务。在该案中，涉案软件采用的是GPL3.0许可协议，其具有“强传染性”特征，对在逻辑上与开源代码有关联性且整体发布的派生作品，只要其中有一部分是采用GPL3.0协议发布，那么整个派生作品都必须受到GPL3.0协议的约束；同时根据该协议第8条“终止授权”的触发条件，规定许可用户必须承担相应的义务才能行使复制、修改或传播的权利，用户的义务即GPL3.0协议的使用条件，包括声明许可协议、开放源代码等。若用户违反上述使用条件，那么其通过GPL3.0协议获得的授权将会自动终止。在该案中，被诉侵权方在分发的过程中没有按照GPL3.0的规定开放源代码，因此违反了许可证的规定，导致因许可证而获得的权利被终止，由于失去了权利来源，因此被诉侵权方对涉案源代码进行的复制、修改和分发构成侵犯著作权。
在软件自由保护协会（SFC）等诉西屋电子的案件中，原告主张被告未经许可在其HDTV产品中使用了Linux开源项目BusyBox的软件（采用GPL2.0协议）。同样的，法院在确认许可协议合同属性的基础上认为被诉侵权方违反了许可协议，因此其持续的复制、修改或分发行为侵犯了原告的著作权，据此判决对被告的HDTV产品下发永久禁令并实施3倍赔偿，同时销毁侵权产品。
可以看出，虽然开源许可协议在形式上较为松散、并没有双方签字确认的形式要件，但属于以实际履行为生效条件的具有合同属性的约定，开源使用者需特别注意所使用的开源软件的协议中对“传染性”、“商用化”、“再分发”等关键权利义务的要求，以避免法律风险。
2、开源软件本身侵犯第三方权利的风险
由于开源软件限定的是对源代码本身的修改、使用和传播，因此许可协议规制的对象仍主要限于对开源项目本身源代码的运用，在开发、使用开源代码的过程中，仍存在对第三方拥有权利的专利权或著作权构成侵权的风险。
Google（谷歌公司）2015年收购Android（安卓）公司后，试图通过安卓为智能手机等移动设备开发软件平台。经与甲骨文公司协商许可使用Java SE未果，谷歌公司自行开发安卓系统，在开发中使用了11,500行Java的接口API中的声明代码，使程序员能够继续通过Java的语言习惯在其开发的软件平台中调用预先编写的程序，而且对安卓平台开源，使软件开发人员免费使用安卓平台上的工具。甲骨文向法院提起诉讼，主张谷歌侵犯了甲骨文拥有的Java类库的版权及两项专利权，其中认为谷歌对37个程序包中的11,500行声明代码和API的非字面组织结构（SSO）构成未经许可的复制。这个案件是典型的开源项目开发者遭遇侵犯他人知识产权的案件。
对于甲骨文对谷歌专利侵权的主张，地区法院陪审团认定不构成专利侵权，且甲骨文并未提起上诉。在版权侵权问题上，双方经历了长达10年的诉讼拉扯，几经反转，于2021年上半年结案。最终美国最高法院做出裁决，认为甲骨文对API代码构成合理使用，裁决从作品性质、使用目的、数量及影响和市场影响四个方面进行了论述，主要包括以下要点：主要认为谷歌复制的是API中的声明代码而非执行代码，该些代码不属于版权保护的核心对象，谷歌复制的Java API仅占总代码的0.4%，且目的并非基于代码体现出的创造性价值，而是为软件开发人员提供熟悉的语言条件， 促进软件的交互性，这一点实际上是有利于甲骨文的，而且如果任凭甲骨文垄断API指令，将不利于维护公共利益。
这个案件对整个安卓开源生态的影响都是深远的，从风险防控角度看，对国内的软件企业也有重要的借鉴意义——在开发软件过程中，即便自己的项目是开源的，也应树立知识产权的保护意识和风险防控意识。
3、未合规使用开源软件的其他潜在法律风险
除了前述知识产权风险，未合规使用开源软件还可能导致如商标侵权、不正当竞争等其他法律风险。比如未经许可使用开源软件、开源项目或开源社区商标，可能导致侵犯商标权。
在很多情况下，开源软件的使用者未仔细甄别开许可协议，还往往导致其开发的商用软件中混入强传染性开源代码，而导致需背负开源义务，进而使商用软件中的某些技术秘密信息丧失秘密属性，更严重的是导致核心代码被开源而引发的商业风险。
Part 02
二、商业风险
2020到2021年是开源软件的投资黄金年，Confluent、GitLab、HashiCorp等一众开源企业先后上市，基于开源软件的初创公司也纷纷在早期就获得巨额融资。从资本的态度可以看出，开源蕴含着极大的商机。开源商业模式是一种创新模式，其采用开放源代码、自由分发等形式减少了营销和销售的成本；通过放弃部分信息不对称产生的潜在利润，换取一定的传播和场景触及率，以达到引领生态流量和技术路径的目标。i在开源生态的商业化过程中，开源协议是整个生态系统的法律基础，也是开源产业可持续发展的制度性保障，从近十年来开源者对于商业化的态度和开源协议的逐渐变化，能够清晰看出开源软件平台如何利用规则达到自身商业利益最大化同时打压想“分一杯羹”的开源使用者。
对我国大部分参与开源的公司来说，大多数还停留在提供技术层面的贡献和对开源软件的使用上，只要还没有掌握规则制定权和话语权，就会存在一系列的商业风险。
1、利用开源软件获取商业利益的空间在不断收紧
长期以来，SaaS服务供应商根据GPLv2第2条b）款的约定，在不公开任何源代码的情况下利用开源软件赚钱（二、你可以修改你的程式副本的任意部分，以构成本程式的派生作品，并在满足上述条款及以下三点要求的前提下复制和分发该修改版：……b)你必须使你分发或发布的作品，部分或全部包含本程式或其派生作品，允许第三方在本协议约束下使用，并不得就授权收费。）因为根据上述约定，只要不发布软件，就不需要公开源代码，这意味着任何人都可以将程序或者程序的修改作为服务向第三方提供。在SaaS场景下，用户通过云端访问软件，软件商不必将软件源代码提供给用户，也就没有GPL协议中“分发”的动作。因此，GPL协议被认为是拥有“SaaS Loophole”（SaaS服务漏洞）。
尽管在很长的一段时间内，并没有开源许可证针对性的对SaaS进行约束，云服务商的这种“白嫖”行为自然不会被坐视不理。在此情况下，AGPL应运而生，其针对分发模式对传统的许可证进行了修补，特别针对SaaS服务进行了限制——AGPL v3的第13条中约定：
13. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network （if your version supports such interaction） an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
（尽管本许可证有任何其他规定，如果您修改本程序，您的修改版本必须在显著位置向所有通过计算机网络远程与本程序互动的用户（如果您的版本支持这种互动）提供机会，通过一些标准或习惯的促进软件复制的方式，从网络服务器上免费提供相应的源码。该相应源码应包括根据下段规定纳入GNU通用公共许可证第3版的任何作品的相应源码。）
根据AGPL v3的以上约定，只要“修改”程序，就会触发AGPL许可证的传染性，进而需要开源包括修改程序在内的所有程序的源代码；而且只要修改是通过“计算机网络远程互动”（包括网络和邮件服务器、基于互动的网络应用程序和在线播放的游戏服务器等）进行互动的场景也被囊括在内。可见这个约定是针对SaaS应用场景的精准投放。尽管“修改”是触发传染的条件，但是这一约定确实让大多数公司对AGPL的使用极其小心，因为一不留意就会导致代码面临被开源的风险。结果是一部分使用者为避免不必要的麻烦，舍弃开源软件转向选择获得商业授权， 这就间接提升了商业软件的竞争力。
2、因许可证变更、闭源导致的风险
由于规则掌握在开源软件拥有者手中，当拥有者意识到自己的商业利益被开源使用者蚕食时，必然会采取措施制止这种利益瓜分。
Mongo DB在2018年宣布将其开源软件的许可证由AGPLv3变更为其自己创建的SSPL许可证（服务器端公共许可），其与AGPLv3最大的区别在于，其舍弃了“修改”作为传染性触发条件的约定，而是明确约定将程序或程序的修改版本的功能作为服务向第三方提供时，需要提供“服务源代码”，并且明确了需要开源的“服务源代码”包括但不限于“管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件，所有这些都是为了让用户可以使用您提供的服务源代码运行服务实例”。这意味着，云服务商在构建SaaS服务时，如果使用的是SSPL许可证开源软件，那么其程序及与程序配套的所有相关软件的程序（包括前台和后台）都必须开源。MongoDB的这一创设确实是对用SaaS赚钱的云服务商的精准定位——对普通用户而言，仍然可以继续使用、修改、分发，而且能够为其商业版提供支持，如果是云服务商，要么就缴械（公开源码），要么就给钱（选择其商业版本）。结果就是云服务商的竞争力被削弱，而开源软件商业版本的竞争力进一步提升，MongoDB因此获利。虽然MongoDB此举在当时受到很大的舆论压力，并遭到红帽公司弃用，但丝毫未影响其商业价值。
相似的，2018年Redis将其开发的Redis模块的许可协议由AGPL改变为Apache v2.0和Commons Clause相结合的许可协议。尽管将Commons Clause应用于开源项目意味着可获取、免费访问、修改和重新分发源代码的自由，但其并不是开源协议。根据其约定，该许可证下完全的限制了使用者销售的权利，也拒绝商业环境。2019年，Redis再次宣布更改许可证，将Redis模块的许可协议变更为RSALv2（源码可用许可）和SSPL相结合的许可协议。虽然Redis的作者一直强调Redis从未变更过许可证，将一直使用BSD许可证。实际上，一直且声称将继续使用BSD许可证的部分只是Redis核心。而Redis Lab的某些模块(RediSearch, Redis Graph， ReJSON， ReBloom ，Redis Stack)则改用RSAL v2和SSPL相结合的许可证。（如下图所示）
（来源：https://redis.com/legal/licenses/ ）
根据RSAL v2许可证，可以使用、复制、分发、衍生源代码，但是不能将软件的功能或者修改版本作为服务提供给第三方，也不能以向第三方提供功能的方式分发或修改。这意味着不能通过应用RSAL v2许可证的项目构建应用程序，也不能提供服务。彻底斩断了利用开源软件提供商业化服务产品的可能性。
2021年， Elasticsearch和Kibana从7.11版本开始，将许可证由Apache 2.0和Elastic License变更为SSPL和Elastic License的双重许可。
从MongoDB到Redis再到Elastic，虽然这几个例子中的许可证最后都归于选择SSPL，但许可证的变更似乎已经成为一种趋势，比如Grafana、Loki 和 Tempo 的开源协议由 Apache License 2.0 变为 AGPL v3；HashiCorp在今年将所有产品从Mozilla v2改为限制商业性使用的商业源代码许可证（BSL）v1.1。
此外，国内外也有一些开源项目或因为商业考虑或因为其他原因而选择直接闭源，这将直接影响基于这些开源软件开发产品的商业利益，如后续开发被掣肘、前期投入落空、后续产品难以维护等等。
3、安全漏洞风险
安全问题是影响开源软件深入商业化运营的重要风险点。然而根据新思科技发布的《开源安全和风险分析》（2023），包括至少一个漏洞的代码库占总样本库的84%，包含保卫漏洞的代码库占比达到48%；高风险漏洞5年增长最多的行业为计算机硬件和半导体、零收和电子商务、制造业和工业机器人、大数据和机器学习以及航天航空汽车运输物流。这些行业包括了国家重点发展的行业和涉及人民生活生产的民生类行业。一旦爆发安全漏洞事件，叠加开源软件本身的性质和特点，会放大安全漏洞事件的波及范围和深度。2021年 ， Apache Log4j2远程代码执行漏洞（CNVD-2021-95914）导致攻击者可在未授权的情况下远程执行代码，漏洞披露5天后，美国网络安全公司Cloudflare观察到每秒400次利用Log4j漏洞的攻击尝试，以及总共数百万次对易受攻击系统的扫描。直至今日，该漏洞的影响依然余波未了。
4、其他商业风险
开源软件与商业软件的运作方式完全不同，如果使用者缺乏认识就很可能导致企业因开源软件使用不当导致利益受损。比如有一些代码库当中有的版本已经过时，但是团队并不知道该开源组件的新版本已经可用，甚至根本不知道该组件的存在；以及使用开源软件时未关注控制组件的安全性和稳定性、新版本和补丁，这些认知的疏漏将导致软件的可靠性及可用性，甚至安全性被大大削弱，进而很可能影响企业的商业效益。
再者，目前主流开源项目如Linux、Apache、Mozilla、MySQL等，其所在地均在美国和欧洲，在地缘政治复杂多变、国际形式云波诡谲的情况下，我们要认识到社区是存在国界线的。在俄乌冲突中，GitHub就限制俄罗斯开发人员使用开源软件，甲骨文、SAP等数据库供应商也宣布暂停在俄罗斯的服务。GitHub CEO 还发文表示，遵守政府提出的出口管制和贸易法规，其中包括严格限制俄罗斯获得其维持侵略性军事能力所需的技术。西方主导的开源社区可以直接对待俄罗斯，也就可以把同样的招数用在我国身上。就在最近，8月10日，美国总统签署了一项行政命令，限制美国对中国大陆、中国香港和澳门主要涉及三个敏感技术的投资活动：半导体和微电子、量子信息技术和人工智能。
自然，开源所倡导的“自由共享、开放协作”精神对促进软件产业快速发展与创新已经并且持续发挥着重要作用。但是，天下熙熙皆为利来，天下攘攘皆为利往，利益争夺才是一个企业的生存发展之本。对于我们国家的众多企业来说，我们还沉浸于拥抱开源获得巨大利益的美好愿景中，然而开源的“源”除了源代码，我们也可以理解为“源头”，源头掌握在手中，谁才能掌握财富的闸门，身处下游的使用商们持续利用开源软件赚钱的权利实际取决于上游开源拥有者们，当下游因上游获得的利益大到让上游的开源拥有者无法坐视不理时，闸门很可能会落下。
问渠那得清如许，为有源头活水来。我们已经享受了四十年开源软件的红利，基础开始、从底层开始创建、经营开源项目对我们的创新能力提出了挑战，这同时也是一个机遇，让我们能够有机会建立自己的规则，树立自己的话语权，从而把基础和核心掌握在自己手里。
注释
[i] 《开源生态白皮书》，中国信息通信研究院，2021年9月
往期热文